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1. Introduction 

Refactoring is a software development strategy that characteristically alters the syntactic struc- 
ture of a program without changing its external behavior [2]. In this talk we present a methodology 
for extracting formal models from programs in order to evaluate how incremental refactorings af- 
fect the verifiability of their structural specifications. We envision that this same technique may 
be applicable to other types of properties such as those that concern the design and maintenance 
of safety-critical systems. 

2. Formal Methodology 

An object-oriented design D consists of a set of classes expressed in Java or another class-based 
object-oriented language. For the purposes of reasoning about D and formally comparing it to its 
refactorings we model D as a first-order theory of the form (E, 7 Z) where E is a relational signature 
extracted from D ' s structural features, and 1Z is a finite set of E-sentences expressing facts or 
axioms that partially capture DA class- level behavior [5]. 1Z may result from the direct study of 
D or its documentation. We will consider the case when 1Z is the output of a particular program 
analysis. 

An additional set of E-sentences, S, provides an abstract specification of what it means for D 
to be correct. The extent to which the set of facts 7 Z, that we hold about D, implies S , is indicative 
of how verifiable the design is by us. Any refactoring, D ' , of D will have the same correctness 
criteria as D. To compare the verifiability of the two designs we assume that there is a signature 
morphism a : E — > S ; between the original and the refactored designs 1 , but a only needs to be 
defined on the subset of E used to express S. Letting 7Z and JZ! be the two sets of facts that we 
hold with respect to each design, we say that D’ is better verifiable than D under the following 
conditions. 

1. For every ip E S, if 1Z implies ip, then 1Z! implies the translated formula u(ip). 

2. For some ip G S, 1Z' implies cr(ip), but TZ does not imply ip. 

The first requirement merely states that D' is a behavior-preserving refactoring of D with respect 
to the verifiable behavior of D. While the second requirement states that we are able to verify D' 
more thoroughly than we are D. 

* This material is based upon work supported by the National Science Foundation under Grant No. NSF 
CNS-0613919. 

1 More precisely the notion of a derivor[ 3] can be used. 
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public class Employee { 

static final int ENGINEER = 0; 
static final int SALESMAN = 1; 
static final int MANAGER = 2; 

private int type ; 
private int monthlySalary ; 
private int commission ; 
private int bonus ; 


public int payAmountQ { 
switch ( type ) { 
case ENGINEER: 

return monthlySalary ; 
case SALESMAN: 

return monthlySalary + commission : 
case MANAGER: 

return monthlySalary + bonus ; 

} 


} 


Initial Design D 



Refactored Design D' 


Figure 1. Initial design D and refactored design D' of the Employee class. 


Alloy [4] is a relational language based on first-order logic that allows us to express theories 
about designs. When combined with the Alloy Analyzer it offers a practical way to implement our 
methodology and to check 1) and 2) in practice. Once (E,7£) is presented as an Alloy theory, the 
Alloy Analyzer enumerates its models up to a user specified depth and reports any counterexample 
that it finds for a particular £ S, each of which is encoded as an Alloy assertion. The same is 
done for (£' ,TZ') and each cr(^). While not a proof, the absence of a counterexample serves as 
evidence that an assertion may be valid within a theory and hence verifiable about a particular 
design. 

3. Implementation 

Next, we describe how we used Alloy and two different automatic constraint detectors to apply 
this methodology to the Employee example of the ‘replace conditional with state’ refactoring from 
Fowler’s book [2]. Figure 1 presents the initial design D as a single class, Employee, providing 
a pay Amount method which uses a switch-statement to compute the monthly earnings of an 
employee based on his or her occupation (type). In the refactored design D' , however, Employee 
delegates the earnings computation to a polymorphic state object, type, which is no longer just 
a simple int, and the computation is now distributed over three different kinds of EmployeeType 
objects. The right side of Figure 1 depicts this design. 

The extraction of E and S' is based on the class structures of D and D ’ and is virtually 
automatic. Each class or datatype is presented as its own disjoint set of atoms, while attributes 
and methods are presented as relations on these sets. The signature morphism a : E — > T,' must be 
constructed by hand. In our example, a is the identity mapping for all sorts and relations except 
for type. The assertions standing for the specification S must also be constructed by hand. For 
instance, one assertion about the payAmount method is that an Engineer's monthly earnings are 
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equal to his or her salary. 

Finally, 1Z and 1Z' consist of the machine translated invariants output by one of the two program 
analysis tools, Daikon [1] or ContExt. One fact that Daikon recovered from the design D 1 states 
that the payAmount method for the Engineer class returns the monthlySalary of its Employee 
attribute. After the two respective Alloy theories, (E, 7 Z) and (S', 1Z 1 ) have been created for designs 
D and D 1 by either Daikon or ContExt, we use the Alloy Analyzer to check whether the set of 
assertions that hold in the refactored theory is a proper superset of the assertions that hold in 
the unrefactored theory. If so, then we conclude that there is evidence to suggest that D' may be 
better verifiable than D in light of the facts obtainable by either tool. 

In this example the Alloy analyzer considered all possible models consisting of two Employee 
entities, two EmployeeType entities and each int from -16 to 15. Our study suggests that the 
verifiability of the refactored design improves with respect to the facts obtained by Daikon, while 
the verifiability of either design is sufficiently good in light of the facts obtained by ConText. 

4. Conclusions 

Insofar as some structural properties of programs are safety-critical, the methodology presented 
here already applies to them. For instance, a specification for a controller may contain a safety- 
critical class invariant that states which configurations are reachable. Our methodology allows 
a way to monitor the verifiability of such properties as refactorings are applied throughout the 
software lifecycle. More investigation is needed to evaluate our approach on a real world example. 
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